Solomon's Key (NES) ROM map (v1.0)

Table of Contents

• Introduction
• Data Tables
• Demon Mirror Drop Rates
• Demon Mirror Enemy Sets
• Enemy Data
• Block Data
• Level Metadata and Item Data
• Game Metadata and open questions
• Map of Enemy Types
• Map of Item Types
• Contact
• Changelog

Introduction

This document describes the ROM map layout for Solomon's Key (NES) to the best of my current knowledge. As more information is gathered, I will update this document. If you have anything to add, see my contact information.

There are several data tables in the ROM: Demon Mirror Drop Rates, Demon Mirror Enemy Sets, Enemy Data and Item Data. The level data sections have the following layout, in order (5120 contiguous bytes):

Information on how to decode the data tables, and the actual data they point to, follows. All numbers which start with 0x are hexadecimal values. Otherwise, they are decimal.

The document often refers to 1-byte positions. The gameboard is 16x12 tiles, and we will call the top left corner position (0, 0).

Given a position byte, the high nibble is the y-position plus one, and the low nibble is the x-position. For example the value 0xb5 gives the position:

(0x5, 0xb - 1) = (0x5, 0xa) = (5, 10)

A high nibble value of 0 gives a y-value of -1, which is not visible on the screen. (this is used to hide the key and door on some of the special rooms)

Data Tables

As described in the introduction, there are four section tables in the ROM. Before decoding data, we need to know how to read these tables.

Each table points to certain locations in the ROM. Each location is given by two bytes; "low" and "high". The table starts at a certain offset in the ROM, and if it points to N different elements, the table consists of 2xN bytes.

The first half of the table describes the low bytes of the element offset, and the second half of the table describes the high bytes.

Example: Find the offset of the enemy data for Room 1 in an unmodified version of the US version of the ROM:

• The enemy data table is located at offset 0x5cfc. The first byte is the low byte of the first level's location: 0x56.
• There are 53 levels in the game, so this table points at 53 different locations. Hence, the high byte of the location we seek is at offset 0x5cfc + 53 = 0x5d31: 0xdd.
• The RAM location of the sought element is then given by concatenating these values: 0xdd56.
• The ROM location is then found by subtracting 0x7ff0 - a constant which describes the difference between ROM and RAM addresses.
• 0xdd56 - 0x7ff0 = 0x5d66. This address corresponds to the start of the enemy data section given in the introduction.

All data tables are decoded in this manner. By knowing the table offset, and the number of elements it contains the locations of - we can now deduce the start of any element's data section in the ROM file.

Information on how decode the actual data for each section follows.

Demon Mirror Drop Rates

The demon mirror drop rate table points to 16 elements, which means that the drop rate table is 32 (2x16) bytes long. In the original game each element is 8 bytes long, and one might wonder why a data table was needed at all.

In any case, the demon mirrors in any level is associated with one of the sixteen drop rates. A drop rate is a bitmask, where a bit turned on means an enemy will be dropped at that time.

The first four bytes, 32 bits, define the intial schedule, which will be played through when the level starts.

The next four bytes, 32 bits, define the looping schedule, which will be played over and over during gameplay, after the initial schedule is done.

Demon Mirror Enemy Sets

The demon mirror enemy sets data table points to 17 elements, which means that the table is 34 (2x17) bytes long. The enemy set data section itself is 42 bytes long, and the enemy sets can be of varying length. In the original game the sets consist of 1-3 monsters.

The demon mirrors in any level is associated with one of the seventeen enemy sets. Combined with one of the sixteen drop rates, there are 16x17 = 272 different combinations; 272 ways in which a demon mirror can behave.

Each enemy set consists of a list of enemy codes, which can be looked up in the Enemy Types table. The value 0x90 signifies end-of-stream for an enemy set list.

The enemy sets data section itself is up to 42 bytes long, and this leaves room for up to 1.47 enemies per set on average.

Enemy Data

Each of the 53 levels has an enemy data section, meaning that the Enemy Data Table consists of 106 (2x53) bytes.

Any given enemy data section is of variable length, as the different levels have varying amounts of enemies in them. The minimum length of an enemy data section is two bytes; one byte for the spawn lifetime, and one byte for the end-of-stream delimiter.

The enemy data section itself is up to 726 bytes long, and this leaves room for up to 5.85 enemies per level on average. Of course a level might have 0 enemies, or up to as many as 16 enemies - but the total data section cannot exceed 726 bytes.

The first byte of the enemy data is the spawn enemy lifetime. This value determines how long Demonheads and Saramandors will live, after they have been spawned in the level. The value can go from 0-255, but this byte is bit-rotated right by 3 bits in the ROM, for some reason. Rotate left and right by 3 bits to convert.

The next bytes will come in pairs; enemy number followed by enemy position.

Every two bytes will thus define an enemy, until the end-of-stream delimiter 0x00 is reached.

See the Enemy Table for information on all possible enemy values.

Block Data

No data table exists for this section, as each entry is of fixed size. The block data section contains the definitions of the level block data, stored as bitmasks. Since each level is 16 by 12 tiles, one level's block definition containts (16x12)/8 = 24 bytes. Each level has a bitmask for brown (breakable) blocks, and white (unbreakable) blocks. The byte size is therefore 24x2 = 48 bytes per level, and with 53 levels the total block data section is 48x53 = 2544 bytes.

For each level, the first 12 bytes define the brown blocks, and the next 12 bytes define the white blocks.

The block data is read from top to bottom, left to right.

It is possible for a brown and white block to be set on the same location. In this case it will count as a white block.

The rightmost row always consists of white blocks in the original game. If one of these blocks is missing, it is possible to walk throught the wall and wrap around.

Item Data

Each of the 53 levels has an item data section, meaning that the Item Data Table consists of 106 (2x53) bytes.

Any given item data section is of variable length, as the different levels have varying amounts of items in them. The item data section contains some level metadata too, and supports a simple compression routine when a level contains several items of the same type.

The first ten bytes of the data section for a given level make up a level metadata header:

Key Status and time decrease rate are stored in the same byte. If the second bit is set, the key is in a block. If the first bit is set, the key is hidden, meaning the player needs to create and destroy a block to reveal the key.

The time decrease rate is the last nibble of this byte, meaning it has a value of 0 (slow time decrease) to 15 (fast time decrease).

After the 10-byte metadata header, the item data follows. The items can come in pairs; item code and position. See the item types section for details on each item code. Valid item codes are 0x01 - 0xbf.

The base item codes are 0x01-0x3f, but the first and second bits can be set to alter the item attributes; first bit set means the item is hidden in a block, second bit set means that the player must create and destroy a block to reveal the item. For this reason the maximum item code including modifiers is 0xbf.

Codes from 0xc0 to 0xdf indicates that the next item will be repeated, and provides a simple kind of compression. Take the code and subtract 0xc0, add one, and you have the number of items. The next byte will give the item code, and the next bytes give the position for each of these duplicate items.

Codes 0x00 or 0xe0 - 0xef indicate end-of-stream, but also tells us which tileset the level uses. Take bits 5 and 6, and AND it with 3 to get the tileset number. (0-2).

Codes 0xf0 - 0xfb indicate constellation picture as well as tileset number. The difference here is that the constellation has a position too, which is the following byte. Once the position is consumed, the stream ends. In other words, constellations act as end-of-streams, and it follows that a level can only have one constellation background.

The tileset number is derived in the same way as for codes 0xe0 - 0xef, and the following table shows which constellations belong to which codes:

Codes 0xfc and up are invalid, and so are 0xec - 0xef really, as there is no usable fourth tileset.

Game Metadata

In addition to the Demon Mirror Drop Rates and Enemy Sets which have already been explained, there is some game metadata which has an effect on individual levels. A table of the known metadata follows, with an explanation underneath:

The 24-byte bitmasks are decoded just like layers of blocks. Instead of blocks, they are layers of items. For level 20 they describe bat symbols (item no 0x04) and for level 30 they descrive blue opals (item no 0x27).

Question: Where are the level number and item number stored? How can we, for example, turn the level 20 bat symbol bitmask into a level 17 star coin bitmask?

Bomb Jacks appear on level 17 and 39. We need to hit the block at the given position 11 times to make Bomb Jack appear.

Question: We know the position of the Bomb Jacks, but how can we deduce from the ROM the levels in which he appears?

Solomon's Seals appear on eight levels. It is not known by the author why this was not part of the item data section for those levels, as Solomon's Seals already have an item code - and there is plenty more space in the total item data in the ROM.

Question: We know the positions of the Solomon's Seals, but how can we deduce from the ROM the levels in which they appear?

In addition to these, there are Tecmo Bunnies on levels 20 and 38, a page of time on level 52 and a page of space on level 53. None of these are part of the level item data, and in fact the Tecmo Bunny is not modeled as an item at all.

Question: Where is the data for the level number and position for the Tecmo Bunnies, and Space/Time Pages?

In addition to this, we would like to know how to deduce which white blocks can be broken.

See the Contact section for how to contact me. Any contribution would be much appreciated as we try to fill in the gaps in our knowledge of the ROM data.

Enemy Types

The following enemies can safely be placed in the levels. The column "Original Use Count" shows how many times the enemy appears in the original ROM. Note that a lot of enemies have duplicate codes. I differentiate between them by adding "#2" to the name of the secondary version.

All enemies, apart from flames, have at least one of the properties "direction" and "speed".

Ghosts and Neul also have a property we call "noslow", which means that the ghost/Neul will not be slowed when turning around after hitting a wall.

Fireballs have a property "cw" or "ccw", which means they will go clockwise or counter-clockwise, respectively, after hitting a wall.

Demonheads and Saramandors only spawn from Demon Mirrors in the original game, but they can be placed in the levels from the start, like any other enemy.

The following table describes glitchy and unusable enemy codes:

Enemy codes 0x84 and up are not in use.

Item Types

The following items can safely be placed in the levels. The column "Original Use Count" shows how many times the item appears in the original ROM. Note also that a few items will look different based on the tileset used. (For example: the warp flag)

To make an item hidden, take its hex value and set the 2nd bit. To make an item appear inside a brown block, set the 1st bit.

The following table describes glitchy and unusable item codes:

Item codes 0xc0 and up are illegal, as they signify other things in the item data stream. See the Item Data section for details.

Contact

This document is written and maintained by Kai E. Frøland aka kaimitai. If you have comments, corrections or other feedback - contact me at kaimitai@pm.me.

Changelog

• 2023-01-21: v1.0 released
• 2023-01-15: v1.0 started